Process control system using a process control strategy distributed among multiple control elements

ABSTRACT

A process controller implements an overall, user-developed control strategy in a process control network that includes distributed controller and field devices, such as Fieldbus and non-Fieldbus devices. A user defines the control strategy by building a plurality of function blocks and control modules and downloading or installing user-specified portions of the control strategy into the Fieldbus devices and the non-Fieldbus devices. Thereafter, the Fieldbus devices automatically perform the downloaded portions of the overall strategy independently of other portions of the control strategy. For example in a process control system that includes distributed field devices, controllers and workstations, portions of the control strategy downloaded or installed into the field devices operate independently of and in parallel with the control operations of the controllers and the workstations, while other control operations manage the Fieldbus devices and implement other portions of the control strategy.

[0001] This application is related to copending application by Nixon etal., entitled “Process Control System for Monitoring and DisplayingDiagnostic Information of Multiple Distributed Devices”, filed on evendate herewith (attorney docket no. M-3926 US), which application ishereby incorporated by reference in its entirety, including anyappendices and references thereto.

[0002] This application is related to copending application by Nixon etal., entitled “Process Control System Including Automatic Sensing andAutomatic Configuration of Devices”, filed on even date herewith(attorney docket no. M-4029 US), which application is herebyincorporated by reference in its entirety, including any appendices andreferences thereto.

[0003] This application is related to copending application by Nixon etal., entitled “A Process Control System User Interface IncludingSelection of Multiple Control Languages”, filed on even date herewith(attorney docket no. M-4045 US), which application is herebyincorporated by reference in its entirety, including any appendices andreferences thereto.

[0004] This application is related to copending application by Dove,entitled “System for Assisting Configuring a Process ControlEnvironment”, filed on even date herewith (attorney docket no. M-3927US), which application is hereby incorporated by reference in itsentirety, including any appendices and references thereto.

[0005] This application is related to copending application by Nixon etal., entitled “Process Control System Using a Control StrategyImplemented in a Layered Hierarchy of Control Modules”, filed on evendate herewith (attorney docket no. M-4028 US), which application ishereby incorporated by reference in its entirety, including anyappendices and references thereto.

[0006] This application is related to copending application by Dove etal., entitled “System for Configuring a Process Control Environment”,filed on even date herewith (attorney docket no. M-3928 US), whichapplication is hereby incorporated by reference in its entirety,including any appendices and references thereto.

[0007] This application is related to copending application by Nixon etal., entitled “Improved Process System ”, filed on even date herewith(attorney docket no. FEMR:004), which application is hereby incorporatedby reference in its entirety, including any appendices and referencesthereto.

BACKGROUND OF THE INVENTION

[0008] 1. Field of the Invention

[0009] This invention relates to process control systems. MorQspecifically, the present invention relates to a process control systemusing a distributed process control strategy.

[0010] 2. Description of the Related Art

[0011] Present-day process control systems use instruments, controldevices and communication systems to monitor and manipulate controlelements, such as valves and switches, to maintain at selected targetvalues one or more process variables, including temperature, pressure,flow and the like. The process variables are selected and controlled toachieve a desired process objective, such as attaining the safe andefficient operation of machines and equipment utilized in the process.Process control systems have widespread application in the automation ofindustrial processes such as the processes used in chemical, petroleum,and manufacturing industries, for example.

[0012] Control of the process is often implemented usingmicroprocessor-based controllers, computers or workstations whichmonitor the process by sending and receiving commands and data tohardware devices to control either a particular aspect of the process orthe entire process as a whole. The specific process control functionsthat are implemented by software programs in these microprocessors,computers or workstations may be individually designed, modified orchanged through programming while requiring no modifications to thehardware. For example, an engineer might cause a program to be writtento have the controller read a fluid level from a level sensor in a tank,compare the tank level with a predetermined desired level, and then openor close a feed valve based on whether the read level was lower orhigher than the predetermined, desired level. The parameters are easilychanged by displaying a selected view of the process and then bymodifying the program using the selected view. The engineer typicallywould change parameters by displaying and modifying an engineer's viewof the process.

[0013] In addition to executing control processes, software programsalso monitor and display a view of the processes, providing feedback inthe form of an operator's display or view regarding the status ofparticular processes. The monitoring software programs also signal analarm when a problem occurs. Some programs display instructions orsuggestions to an operator when a problem occurs. The operator who isresponsible for the control process needs to view the process from hispoint of view. A display or console is typically provided as theinterface between the microprocessor based controller or computerperforming the process control function and the operator and alsobetween the programmer or engineer and the microprocessor basedcontroller or computer performing the process control function.

[0014] Systems that perform, monitor, control, and feed back functionsin process control environments are typically implemented by softwarewritten in high-level computer programming languages such as Basic,Fortran or C and executed on a computer or controller. These high-levellanguages, although effective for process control programming, are notusually used or understood by process engineers, maintenance engineers,control engineers, operators and supervisors. Higher level graphicaldisplay languages have been developed for such personnel, such ascontinuous function block and ladder logic. Thus each of the engineers,maintenance personnel, operators, lab personnel and the like, require agraphical view of the elements of the process control system thatenables them to view the system in terms relevant to theirresponsibilities.

[0015] For example, a process control program might be written inFortran and require two inputs, calculate the average of the inputs andproduce an output value equal to the average of the two inputs. Thisprogram could be termed the AVERAGE function and may be invoked andreferenced through a graphical display for the control engineers. Atypical graphical display may consist of a rectangular block having twoinputs, one output, and a label designating the block as AVERAGE. Adifferent program may be used to create a graphical representation ofthis same function for an operator to view the average value. Before thesystem is delivered to the customer, these software programs are placedinto a library of predefined user selectable features. The programs areidentified by function blocks. A user may then invoke a function andselect the predefined graphical representations to create differentviews for the operator, engineer, etc. by selecting one of a pluralityof function blocks from the library for use in defining a processcontrol solution rather than having to develop a completely new programin Fortan, for example.

[0016] A group of standardized functions, each designated by anassociated function block, may be stored in a control library. Adesigner equipped with such a library can design process controlsolutions by interconnecting, on a computer display screen, variousfunctions or elements selected with the function blocks to performparticular tasks. The microprocessor or computer associates each of thefunctions or elements defined by the function blocks with predefinedtemplates stored in the library and relates each of the programfunctions or elements to each other according to the interconnectionsdesired by the designer. Ideally, a designer could design an entireprocess control program using graphical views of predefined functionswithout ever writing one line of code in Fortran or other high-levelprogramming language.

[0017] One problem associated with the use of graphical views forprocess control programming is that existing systems allow only theequipment manufacturer, not a user of this equipment, to create his owncontrol functions, along with associated graphical views, or modify thepredefined functions within the provided library.

[0018] New process control functions are designed primarily by companieswho sell design systems and not by the end users who may have aparticular need for a function that is not a part of the standard set offunctions supplied by the company. The standardized functions arecontained within a control library furnished with the system to the enduser. The end user must either utilize existing functions supplied withthe design environment or rely on the company supplying the designenvironment to develop any desired particular customized function forthem. If the designer is asked to modify the parameters of theengineer's view, then all other views using those parameters have to berewritten and modified accordingly because the function program and viewprograms are often developed independently and are not part of anintegrated development environment. Clearly, such procedure is verycumbersome, expensive, and time-consuming.

[0019] Another problem with existing process control systems is a usageof centralized control, typically employing a central controller in anetwork, executing a program code that is customized for specialized,user-defined control tasks. As a result, the process control systems aretypically constrained to a particular size and difficult to adapt overtime to arising needs. Similarly, conventional process control systemsare inflexible in configuration, often requiring a complete softwarerevision for the entire system when new devices are incorporated.Furthermore, the conventional process control systems tend to beexpensive and usually perform on the functions initially identified by auser or a system designer that are only altered or reprogrammed toperform new functions by an expert who is familiar with the entirecontrol system configuration and programming.

[0020] A further problem with existing process control systems is thatthe physical implementation of different systems is highly variable,including control devices and field devices that have a wide range of“intelligence”. For example, some field devices, such as valves, motorsand regulators, may have no computational or control capability. Otherfield devices may have a high level of control autonomy. Still otherdevices may have some computational strength, but not a sufficientamount to accomplish a desired control task.

[0021] What is needed is a uniform or universal design environment thatcan easily be used, not only by a designer or manufacturer but also auser, to customize a control process to the physical constraints of theprocess, utilizing control capabilities various controllers and devices,supplementing these control capabilities when desired and distributingcontrol functionality flexibly throughout the process control system tomeet specific needs for developing process control functions. What isfurther needed is a personal computer-based process control system thatis easily implemented within substantially any size process and which isupdated by users, without the aid of the control system designer, toperform new and different control functions by distributing thesecontrol functions throughout the control system including all central,intermediate and peripheral levels.

SUMMARY OF THE INVENTION

[0022] In accordance with the present invention, a process controllerimplements an overall, user-developed control strategy in a processcontrol network that includes distributed controller and field devices,such as Fieldbus and non-Fieldbus devices. A user defines the controlstrategy by building a plurality of function blocks and control modulesand downloading or installing user-specified portions of the controlstrategy into the Fieldbus devices and the non-Fieldbus devices.Thereafter, the Fieldbus devices automatically perform the downloadedportions of the overall strategy independently of other portions of thecontrol strategy. For example in a process control system that includesdistributed field devices, controllers and workstations, portions of thecontrol strategy downloaded or installed into the field devices operateindependently of and in parallel with the control operations of thecontrollers and the workstations, while other control operations managethe Fieldbus devices and implement other portions of the controlstrategy.

[0023] In accordance with one embodiment of the present invention, aprocess control system includes a field device, a controller connectedto the field device, a workstation connected to the controller, and asoftware system. The software system implements a control strategy forthe process control system. The control strategy is selectivelyapportioned into a plurality of control strategy modules and selectivelydistributed among the field device, controller and workstation, thecontrol strategy modules operating mutually independently and inparallel.

[0024] In accordance with another embodiment of the present invention, amethod of operating a process control system including a distributedcontroller and a distributed field device includes the steps of defininga control strategy further including the substeps of building aplurality of function blocks and control modules and downloadinguser-specified function blocks and control modules selectively among thedistributed controller and the distributed field device. The method ofoperating the process control system further includes the step ofexecuting the function blocks and control modules distributed to thecontroller and distributed to the field device mutually independentlyand in parallel.

[0025] The described process control system and operating method hasmany advantages. One advantage is that the system supplies a uniform,universal design environment for users of many various expertise,experience and training levels to customize a control process to thephysical constraints of the process. A further advantage is that thedescribed system uses control capabilities of various controllers anddevices, supplementing these control capabilities when desired anddistributing control functionality flexibly throughout the processcontrol system as needed. Another advantage is that the process controlsystem is easily based on a personal computer-based design which iseasily implemented within substantially any size process and which isupdated by users, without the aid of the control system designer, toperform new and different control functions. This flexibility isachieved by distributing control functions throughout the control systemincluding all central, intermediate and peripheral levels.

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The features of the invention believed to be novel arespecifically set forth in the appended claims. However, the inventionitself, both as to its structure and method of operation, may best beunderstood by referring to the following description and accompanyingdrawings.

[0027]FIGS. 1A, 1B and 1C illustrate a screen display, a first schematicblock diagram and a second schematic block diagram, respectively,process control systems in accordance with a generalized embodiment ofthe present invention which furnishes a capability to create a newcontrol template and a capability to modify an existing control templatefor only one view, such as an engineering view.

[0028]FIG. 2 is a schematic block diagram showing the process controlenvironment in a configuration implementation and a run-timeimplementation.

[0029]FIG. 3 is a block diagram illustrating a user interface for usagewith both configuration and run-time models of the process controlenvironment.

[0030]FIG. 4 is a schematic block diagram which depicts a hierarchicalrelationship among system objects of a configuration model in accordancewith an embodiment of the present invention.

[0031]FIG. 5 is a schematic block diagram which depicts a configurationarchitecture that operates within the hierarchical relationshipillustrated in FIG. 4.

[0032]FIG. 6 is a block diagram illustrating an example of an elementalfunction block, which is one type of system object within theconfiguration model definition.

[0033]FIG. 7 is a block diagram depicting an example of a compositefunction block, which is another type of system object within theconfiguration model definition.

[0034]FIG. 8 is a block diagram illustrating an example of a controlmodule, which is another type of system object within the configurationmodel definition.

[0035]FIG. 9 is a block diagram showing a module instance, specificallya control module instance, which is created in accordance with thecontrol module definition depicted in FIG. 8.

[0036]FIG. 10 is a flow chart which shows an example of execution of acontrol module at run-time.

[0037]FIG. 11 is a flow chart which shows an example of a module at ahighest layer of a control structure.

[0038]FIG. 12 is a block diagram which illustrates an object-orientedmethod for installing a process I/O attribute block into a PIO device.

[0039]FIG. 13 is a block diagram depicting an object-oriented method forlinking a control module input attribute to a PIO attribute.

[0040]FIG. 14 is a block diagram showing an object-oriented method forlinking a control module output attribute to a PIO attribute.

[0041]FIG. 15 is a block diagram showing an object-oriented method forreading values of contained PIO attributes.

[0042]FIG. 16 is a block diagram which illustrates an organization ofinformation for an instrument signal tag.

[0043]FIG. 17 is a flow chart illustrating a method for bootstraploading a control system throughout a network in the process controlenvironment.

[0044]FIG. 18 is an object communication diagram illustrating a methodfor creating a device connection for an active, originating side of theconnection.

[0045]FIG. 19 is an object communication diagram illustrating a methodfor creating a device connection for a passive, listening side of theconnection.

[0046]FIG. 20 is an object communication diagram illustrating a methodfor sending request/response messages between devices.

[0047]FIG. 21 is an object communication diagram illustrating a methoddownloading a network configuration.

DETAILED DESCRIPTION OF THEE PREFERRED EMBODIMENTS

[0048] Referring to FIG. 1A, a control system is shown. In general, thesystem 1 includes a main processing device, such as personal computer 2,that is connected to a local area network (“LAN”) 3 via a local areanetwork card. Although any local area network protocol may be used, anon-proprietary ethernet protocol is beneficial in many applicationsbecause it allows for communications with the local area network 3. Thelocal area network 3 is dedicated to carrying control parameters,control data and other relevant information concerned in the processcontrol system. As such, the LAN 3 may be referred to as an areacontrolled network or ACN 3. The ACN 3 may be connected to other LANsfor sharing information and data via a hub or gateway without affectingthe dedicated nature of ACN 3.

[0049] In accordance with standard ethernet protocol, a plurality ofphysical devices may be connected to the ACN 3 at various “nodes.” Eachphysical device connected to the ACN 3 is connected at a node and eachnode is separately addressable according the LAN protocol used toimplement ACN 3.

[0050] To establish a redundant system, it may be desirable to constructACN 3 from two or more ethernet systems such that the failure of asingle ethernet or LAN system will not result in the failure of theentire system. When such “redundant ethemets” are used the failure ofone ethernet LAN can be detected and an alternate ethernet LAN can bemapped in to provide for the desired functionality of ACN 3.

[0051] The main personal computer (“PC”) A forms a node on the ACN 3.The PC 2 may, for example, be a standard personal computer running astandard operating system such as Microsoft's Window NT system. Main PC2 is configured to generate, in response to user input commands, variouscontrol routines that are provided via the ACN 3 to one or more localcontrollers identified as element 4 and 5 which implement the controlstrategy defined by the control routines selected and established inmain PC 2. Main PC 2 may also be configured to implement direct controlroutines on field devices such as pumps, valves, motors and the like viatransmission across the ACN 3, rather than through a local controller 4or 5.

[0052] Local controllers 4 and 5 receive control routines and otherconfiguration data through the ACN 3 from PC 2. The local controllersthen generate signals of various types to various field devices (such aspumps, motors, regulator valves, etc.) 6 through 15 which actuallyimplement and perform physical steps in the field to implement thecontrol system established by the routines provided by PC 2.

[0053] Two types of field devices may be connected to local controller 4and 5 including field devices 6 through 10 which are responsive tospecific control protocol such as FieldBus, Profibus and the like. Asthose in the art will appreciate, there are standard control protocols(e.g. FieldBus) according to which specific protocol instructions areprovided to a protocol-friendly field devices (e.g., a Fieldbus fielddevices) will cause a controller located within the field device toimplement a specific function corresponding to the protocol function.Accordingly, field devices 6 through 11 receive protocol specific (e.g.,FieldBus) control commands from either the local controllers 4 and 5 orthe personal computer 2 to implement a field device-specific function.

[0054] Also connected to local controllers 4 and 5 are non-protocolfield devices 12 through 15, which are referred to as non-protocolbecause they do not include any local processing power and can respondto direct control signals. Accordingly, field devices 12 through 15 arenot capable of implementing functions that would be defined by specificcontrol protocol such as the FieldBus control protocol.

[0055] Functionality is supplied to allow the non-protocol field devices12 through 15 to operate as protocol-friendly (e.g., FieldBus specific)devices 6 through 11. Additionally, this same functionality allows forthe implementation of the protocol-specific control routines to bedistributed between the local field devices 6 through 11, the localcontrollers 4 and 5 and the personal computer 2.

[0056] The distribution of protocol-specific control routines isillustrated in more detail in FIG. 1B. FIG. 1B refers to one portion ofthe system shown in FIG. 1A, specifically the personal computer 2, theethernet 3, local controller 4, a smart field device 6 and a dumb device12, in greater detail.

[0057] Personal computer 2 includes program software routines forimplementing standard functional routines of a standard control protocolsuch as the FieldBus protocol. Accordingly, personal computer 2 isprogrammed to receive FieldBus commands and to implement all of thefunctional routines for which a local field device having Fieldbuscapabilities could implement. The ability and steps required to programpersonal computer 2 to implement FieldBus block functionality will beclearly apparent to one of ordinary skill in the art.

[0058] Connected to personal computer 2 by the ethernet 3 is localcontroller 4. Local controller 4 included as central processing unitconnected to a random access memory which provides control signals toconfigure the central processing unit to implement appropriateoperational fictions. A read only memory is connected to the randomaccess memory. The read only memory is programmed to include controlroutines which can configure the central processing unit to implementall of the functional routines of a standard control protocol such asFieldBus. Personal computer 2 sends signals through ethernet 3 to thelocal controller 4 which causes one, more or all of the programmerroutines in the read only memory to be transferred to the random accessmemory to configure the CPU to implement one, more or all of thestandard control protocol routines such as the FieldBus routines.

[0059] The smart field device 5 includes a central processing unit whichimplements certain control functions. If the devices is, for example, aFieldBus device then the central processing unit associated with thefield device 5 is capable of implementing all of the FieldBusfunctionality requirements.

[0060] Because the local controller 4 has the ability to implementFieldBus specific controls, controller 4 operates so that non-protocoldevice 12 acts and is operated as a FieldBus device. For example, if acontrol routine is running either in personal computer 2 or on the CPUof local controller 4, that control routine can implement and provideFieldBus commands to FieldBus devices 5 and 12. Since field device 5 isa FieldBus device, device 5 receives these commands and therebyimplements the control functionality dictated by those commands.Non-protocol device 12, however, works in conjunction with the centralprocessing unit of local controller 4 to implement the FieldBusrequirements such that the local controller in combination with thefield device implements and operates FieldBus commands.

[0061] In addition to allowing non-FieldBus device 12 to act and operateas a FieldBus device, the described aspect allows for distribution ofFieldBus control routines throughout the system 1. For example, to theextent that a control routine initially requests field device 5 toimplement more than one FieldBus control routines, the system I allowsfor control to the divided between the local controller 4 and the fielddevice 5 such that a portion of the FieldBus control routines are beingimplemented by local controller 5 and other FieldBus routines areimplemented by the use of the FieldBus routines stored on localcontroller 4. The division of FieldBus routine implementation may allowfor more sophisticated and faster control and more efficient utilizationof the overall processing power of the system. Still further, the factthat personal computer 2 has the ability to implement FieldBus controlroutines, the FieldBus routines are further distributed between thelocal controller 4 and the personal computer 2. In this manner, thesystem allows personal computer 2 to implement one or all of theFieldBus routines for a particular control algorithm.

[0062] Still further, the system allows for the implementation ofFieldBus controls to a non-FieldBus device connected directly to theethernet 3 through use of the FieldBus control routines stored onpersonal computer 2 in the same manner that FieldBus routines areimplemented on non-FieldBus device 12 through use on the FieldBusroutines stored on local controller 4.

[0063] A process control environment 100 is shown in FIG. 1C andillustrates a control environment for implementing a digital controlsystem, process controller or the like. The process control environment100 includes an operator workstation 102, a laboratory workstation 104,and an engineering workstation 106 electrically interconnected by alocal area network (“LAN”) 108 for transferring and receiving data andcontrol signals among the various workstations and a plurality ofcontroller/multiplexers 110. The workstations 102, 104, 106 are shownconnected by the LAN 108 to a plurality of the controller/multiplexers110 that electrically interface between the workstations and a pluralityof processes 112. In multiple various embodiments, the LAN 108 includesa single workstation connected directly to a controller/multiplexer 110or alternatively includes a plurality of workstations, for example treeworkstations 102, 104, 106, and many controller/multiplexers 110depending upon the purposes and requirements of the process controlenvironment 100. In some embodiments, a single processcontroller/multiplexer 110 controls several different processes 112 oralternatively controls a portion of a single process.

[0064] In the process control environment 100, a process controlstrategy is developed by creating a software control solution on theengineering workstation 106, for example, and transferring the solutionvia the LAN 108 to the operator workstation 102, lab workstation 104,and to controller/multiplexer 110 for execution. The operatorworkstation 102 and lab workstation 104 supply interface displays to thecontrol/monitor strategy implemented in the controller/multiplexer 110and communicates to one or more of the controller/multiplexers 110 toview the processes 112 and change control attribute values according tothe requirements of the designed solution. The processes 112 are formedfrom one or more field devices, which may be smart field devices orconventional (non-smart) field devices. The process 112 isillustratively depicted as two Fieldbus devices 132, a HART (highwayaddressable remote transducer) device 134 and a conventional fielddevice 136.

[0065] In addition, the operator workstation 102 and lab workstation 104communicate visual and audio feedback to the operator regarding thestatus and conditions of the controlled processes 112. The engineeringworkstation 106 includes a central processing unit (CPU) 116 and adisplay and input/output or user-interface device 118 such as akeyboard, light pen and the like. The CPU 116 typically includes adedicated memory 117. The dedicated memory 117 includes a digitalcontrol system program 115 that executes on the CPU 116 to implementcontrol operations and functions of the process control environment 100.The operator workstation 102, the lab workstation 104 and otherworkstations (not shown) within the process control environment 100include at least one central processing unit (not shown) which iselectrically connected to a display (not shown) and a user-interfacedevice (not shown) to allow interaction between a user and the CPU. Inone embodiment, the process control environment 100 includesworkstations implemented using a Motorola 68040 processor and a Motorola68360 communications processor running in companion mode with the 68040with primary and secondary ethernet ports driven by the 68360 processor(SCC1 and SCC3 respectively).

[0066] The process control environment 100 also includes a templategenerator 124 and a control template library 123 which, in combination,form a control template system 120. A control template is defined as thegrouping of attribute functions that are used to control a process andthe methodology used for a particular process control function, thecontrol attributes, variables, inputs, and outputs for the particularfunction and the graphical views of the function as needed such as anengineer view and an operator view.

[0067] The control template system 120 includes the control templatelibrary 123 that communicates with the template generator 124. Thecontrol template library 123 contains data representing sets ofpredefined or existing control template functions for use in processcontrol programs. The control template functions are the templates thatgenerally come with the system from the system designer to the user. Thetemplate generator 124 is an interface that advantageously allows a userto create new control template functions or modify existing controltemplate functions. The created and modified template functions areselectively stored in the control template library 123.

[0068] The template generator 124 includes an attributes and methodslanguage generator 126 and a graphics generator 128. The attributes andmethods language generator 126 supplies display screens that allow theuser to define a plurality of attribute functions associated with thecreation of a new control template function or modification of aparticular existing control template function, such as inputs, outputs,and other attributes, as well as providing display screens for enablingthe user to select methods or programs that perform the new or modifiedfunction for the particular control template. The graphics generator 128furnishes a user capability to design graphical views to be associatedwith particular control templates. A user utilizes the data stored bythe attributes and methods language generator 126 and the graphicsgenerator 128 to completely define the attributes, methods, andgraphical views for a control template. The data representing thecreated control template function is generally stored in the controltemplate library 123 and is subsequently available for selection andusage by an engineer for the design of process control solutions.

[0069] The process control environment 100 is implemented using anobject-oriented framework. An object-oriented framework usesobject-oriented concepts such as class hierarchies, object states andobject behavior. These concepts, which are briefly discussed below, arewell known in the art. Additionally, an object-oriented framework may bewritten using object-oriented programming languages, such as the C++programming language, which are well-known in the art, or may bewritten, as is the case with the preferred embodiment, using anon-object programming language such as C and implementing anobject-oriented framework in that language.

[0070] The building block of an object-oriented framework is an objectAn object is defined by a state and a behavior. The state of an objectis set forth by fields of the object. The behavior of an object is setforth by methods of the object Each object is an instance of a class,which provides a template for the object. A class defines zero or morefields and zero or more methods.

[0071] Fields are data structures which contain information defining aportion of the state of an object. Objects which are instances of thesame class have the same fields. However, the particular informationcontained within the fields of the objects can vary from object toobject Each field can contain information that is direct, such as aninteger value, or indirect, such as a reference to another object.

[0072] A method is a collection of computer instructions which can beexecuted in CPU 116 by computer system software. The instructions of amethod are executed, i.e., the method is performed, when softwarerequests that the object for which the method is defined perform themethod. A method can be performed by any object that is a member of theclass that includes the method. The particular object performing themethod is the responder or the responding object When performing themethod, the responder consumes one or more arguments, i.e., input data,and produces zero or one result, i.e., an object returned as output dataThe methods for a particular object define the behavior of that object.

[0073] Classes of an object-oriented framework are organized in a classhierarchy. In a class hierarchy, a class inherits the fields and methodswhich are defined by the superclasses of that class. Additionally, thefields and methods defined by a class are inherited by any subclasses ofthe class. I.e., an instance of a subclass includes the fields definedby the superclass and can perform the methods defined by the superclass.Accordingly, when a method of an object is called, the method that isaccessed may be defined in the class of which the object is a member orin any one of the superclasses of the class of which the object is amember. When a method of an object is called, process controlenvironment 100 selects the method to run by examining the class of theobject and, if necessary, any superclasses of the object.

[0074] A subclass may override or supersede a method definition which isinherited from a superclass to enhance or change the behavior of thesubclass. However, a subclass may not supersede the signature of themethod. The signature of a method includes the method's identifier, thenumber and type of arguments, whether a result is returned, and, if so,the type of the result. The subclass supersedes an inherited methoddefinition by redefining the computer instructions which are carried outin performance of the method.

[0075] Classes which are capable of having instances are concreteclasses. Classes which cannot have instances are abstract classes.Abstract classes may define fields and methods which are inherited bysubclasses of the abstract classes. The subclasses of an abstract classmay be other abstract classes; however, ultimately, within the classhierarchy, the subclasses are concrete classes.

[0076] All classes defined in the disclosed preferred embodiment, exceptfor mix-in classes which are described below, are subclasses of a class,Object. Thus, each class that is described herein and which is not amix-in class inherits the methods and fields of class Object.

[0077] The process control environment 100 exists in a configurationmodel or configuration implementation 210 and a run-time model orrun-time implementation 220 shown in FIG. 2. In the configurationimplementation 210, the component devices, objects, interconnections andinterrelationships within the process control environment 100 aredefined. In the run-time implementation 220, operations of the variouscomponent devices, objects, interconnections and interrelationships areperformed. The configuration implementation 210 and the run-timeimplementation 220 are interconnected by downloading. The downloadlanguage creates system objects according to definitions supplied by auser and creates instances from the supplied definitions. Specifically,a completely configured Device Table relating to each device isdownloaded to all Workstations on startup and when the Device Table ischanged. For controller/multiplexers 110, a downloaded Device Table onlyincludes data for devices for which the controller/multiplexer 110 is toinitiate communications based on remote module data configured and usedin the specific controller/multiplexer 110. The Device Table isdownloaded to the controller/multiplexer 110 when other configurationdata is downloaded. In addition to downloading definitions, the downloadlanguage also uploads instances and instance values. The configurationimplementation 210 is activated to execute in the run-timeimplementation 220 using an installation procedure. Also, networkcommunications parameters are downloaded to each device whenconfiguration data are downloaded and when a value is changed.

[0078] The process control environment 100 includes multiple subsystemswith several of the subsystems having both a configuration and arun-time implementation. For example, a process graphic subsystem 230supplies user-defined views and operator interfacing to the architectureof the process control environment 100. The process graphic subsystem230 has a process graphic editor 232, a part of the configurationimplementation 210, and a process graphic viewer 234, a portion of therun-time implementation 220. The process graphic editor 232 is connectedto the process graphic viewer 234 by an intersubsystem interface 236 inthe download language. The process control environment 100 also includesa control subsystem 240 which configures and installs control modulesand equipment modules in a definition and module editor 242 and whichexecutes the control modules and the equipment modules in a run-timecontroller 244. The definition and module editor 242 operates within theconfiguration implementation 210 and the run-time controller 244operates within the run-time implementation 220 to supply continuous andsequencing control functions. The definition and module editor 242 isconnected to the run-time controller 244 by an intersubsystem interface246 in the download language. The multiple subsystems are interconnectedby a subsystem interface 250.

[0079] The configuration implementation 210 and the run-timeimplementation 220 interface to a master database 260 to support accessto common data structures. Various local (non-master) databases 262interface to the master database 260, for example, to transferconfiguration data from the master database 260 to the local databases262 as directed by a user. Part of the master database 260 is apersistent database 270. The persistent database 270 is an object whichtranscends time so that the database continues to exist after thecreator of the database no longer exists and transcends space so thatthe database is removable to an address space that is different from theaddress space at which the database was created. The entireconfiguration implementation 210 is stored in the persistent database270.

[0080] The master database 260 and local databases 262 are accessible sothat documentation of configurations, statistics and diagnostics areavailable for documentation purposes.

[0081] The run-time implementation 220 interfaces to the persistentdatabase 270 and to local databases 262 to access data structures formedby the configuration implementation 210. In particular, the run-timeimplementation 220 fetches selected equipment modules, displays and thelike from the local databases 262 and the persistent database 270. Therun-time implementation 220 interfaces to other subsystems to installdefinitions, thereby installing objects that are used to createinstances, when the definitions do not yet exist, instantiating run-timeinstances, and transferring information from various source todestination objects.

[0082] Device Tables are elements of the configuration database that arelocal to devices and, in combination, define part of the configurationimplementation 210. A Device Table contains information regarding adevice in the process control environment 100. Information items in aDevice Table include a device ID, a device name, a device type, a PCNnetwork number, an ACN segment number, a simplex/redundant communicationflag, a controller MAC address, a comment field, a primary internetprotocol (IP) address, a primary subnet mask, a secondary IP address anda secondary subnet mask.

[0083] Referring to FIG. 3, a block diagram illustrates a user interface300 for usage with both the configuration and run-time models of theprocess control environment 100. Part of the user interface 300 is theExplorer™ 310, an interfacing program defined under the Windows NT™operating system which features a device-based configuration approach.Another part of the user interface 300 is a module definition editor 320for interfacing using a control-based configuration approach.

[0084] The Explorer™ 310 is operated by a user to select, construct andoperate a configuration. In addition, the Explorer™ 310 supplies aninitial state for navigating across various tools and processors in anetwork. A user controls the Explorer™ 310 to access libraries, areas,process control equipment and security operations. FIG. 3 illustratesthe relationship between various tools that may be accessed by a taskoperating within the process control environment 100 and therelationship between components of the process control environment 100such as libraries, areas, process control equipment and security. Forexample, FIG. 3 shows that, when a user selects a “show tags” functionfrom within an area, a “tag list builder” is displayed, showing a listof control and I/O flags. From the tag list builder, the user can use an“add tag” function to add a module to a list, thereby invoking a “moduleeditor”.

[0085] Referring to FIG. 4, a schematic block diagram illustrates ahierarchical relationship among system objects of a configuration model400. The configuration model 400 includes many configuration aspectsincluding control, I/O, process graphics, process equipment, alarms,history and events. The configuration model 400 also includes a devicedescription and network topology layout.

[0086] The configuration model hierarchy 400 is defined for usage by aparticular set of users for visualizing system object relationships andlocations and for communicating or navigating maintenance informationamong various system objects. For example, one configuration modelhierarchy 400, specifically a physical plant hierarchy, is defined forusage by maintenance engineers and technicians for visualizing physicalplant relationships and locations and for communicating or navigatingmaintenance information among various instruments and equipment in aphysical plant An embodiment of a configuration model hierarchy 400 thatforms a physical plant hierarchy supports a subset of the SP88 physicalequipment standard hierarchy and includes a configuration model site410, one or more physical plant areas 420, equipment modules 430 andcontrol modules 440.

[0087] The configuration model hierarchy 400 is defined for a singleprocess site 410 which is divided into one or more named physical plantareas 420 that are defined within the configuration model hierarchy 400.The physical plant areas 420 optionally contain tagged modules, each ofwhich is uniquely instantiated within the configuration model hierarchy400. A physical plant area 420 optionally contains one or more equipmentmodules 430. An equipment module 430 optionally contains other equipmentmodules 430, control modules 440 and function blocks. An equipmentmodule 430 includes and is controlled by a control template that iscreated according to one of a number of different graphical processcontrol programming languages including continuous function block,ladder logic, or sequential function charting (“SFC”). The configurationmodel hierarchy 400 optionally contains one or more control modules 440.A control module 440 is contained in an object such as a physical plantarea 420, an equipment module 430 or another control module 440. Acontrol module 440 optionally contains objects such as other controlmodules 440 or function blocks. The control module 440 is thus acontainer class, having instances which are collections of otherobjects. The control module 444 is encapsulated so that all of thecontents and the implementation of the methods of the control module arehidden.

[0088] Referring to FIG. 5, a schematic block diagram shows aconfiguration architecture 500 that operates within the configurationmodel hierarchy 400 illustrated in FIG. 4. The configurationarchitecture 500 includes a several objects and classes at multiplelevels of abstraction. At an organizational level of abstraction 510,the configuration architecture 500 includes a site class 512 whichcontains “named” objects and classes within the configurationarchitecture 500. Named objects and classes are definitions, displaycomponents such as screens and graphics and other items. The namedobjects and classes include function blocks, user accounts, modules,plant areas, events, libraries and other site-wide information. Examplesof named items are block definitions, equipment module definitions,control module definitions, plant area names and the like.

[0089] At a primitive level of abstraction 520, the configurationarchitecture 500 includes primitives that define the interfaces tofunctions within the configuration architecture 500, includinghard-coded functions such as “+”. The primitive level of abstraction 520includes the classes of functions 522 and parameters 524. Functions 522are operational functions at the lowest level of abstraction in theconfiguration architecture 500. Functions 522 are typically coded in theC or C++ languages. In one embodiment of the configuration architecture500, the full set of implemented function blocks 522 are primitives.Objects and classes at the primitive level of abstraction 520 aredefined throughout the site class 512. Parameters 524 are classes andobjects at the lowest level of abstraction in the configurationarchitecture.

[0090] Parameters 524 include integer numbers, real numbers, vectors,arrays and the like.

[0091] Attribute values are mapped into parameters 524 for usage withina function block 522. In one embodiment, function blocks 522 at theprimitive level of abstraction 520 include the function block primitiveslisted in TABLE I, as follows: TABLE I Function Blocks Function BlockDescription/Comments Action Handles simple assignment statements usingHawk expression capability. ADD Simple Add function with extensibleinputs. Al FF Standard Analog Input AI Lite A scaled back version of theFF analog input. AI HART The EF Standard Analog Input with some extraability to handle HART devices. AND Simple And function with extensibleinputs. AO FF Standard Analog Output (From FF standard specification)Arithmetic FF Standard Arithmetic Blo& (From FF standard specification)BDE_TRIGGER Simple bi-directional edge trigger. BIASGAIN FF StandardBias/Gain. (From FF standard specification) CALC/LOGIC Advancedcalculation and logic block that has its own language as well as theability to handle simple ST (1131). It has extensible inputs, extensibleoutputs, and the ability to create temporary variables. ConditionHandles simple condition statements using Hawk expression capability.Counter Simple up/down counter that handles several differentAccumulation methods. CTLSEL FF Standard Control Selector. (From FFstandard specification) DI FF Standard Discrete Input (From FF standardspecification) DI Lite A scaled back version of the FF discrete input.DIVIDE Simple Divide. DO FF Standard Discrete Output. (From FF standardspecification) DT FF Standard Deadtime with advanced control researchimplemented. (From FF standard specification) DtoI A boolean fan in thatconverts up to 16 discrete inputs to a 16-bit integer value. Also hassome special abilities for capturing input patterns. FILT Simple filter.H/L MON LIMIT Simple high/low signal monitor and limiter. INTEGRATOR FFStandard Integrator block. (From FF standard specification) ItoD Booleanfan-out. Takes a 16-bit integer and translates it into 16 discreteoutputs. L/L FF Standard LeadLag with 2 additional types of equations toselect. (From FF standard specification) LOOP An I/O and control blockwith the abilities of AI PID, and AO rolled into one block. LOOPD An I/Oand control block with the abilities of DI, Device Control, and DOrolled into one block. MAN FF Standard Manual Loader. (From FF standardspecification) MULTIPLEX Simple multiplexor with extensible inputs.MULTIPLY Simple multiply with extensible inputs. NDE_TRIGGER Simplenegative edge trigger. NOT Simple not. OFF_DELAY Simple off-delay timer.ON_DELAY Simple on-delay timer. OR Simple logical or with extensibleinputs. P/PD FF Standard P/PD. (From FF standard specification)PDE_TRIGGER Simple positive directional edge trigger. PERIOD Simplemonitor that triggers when an input is true for a specified period PI FFStandard Pulse Input (From FF standard specification) PID FF StandardPID with many additions including the ability to choose algorithm type,form, and structure. (From FF standard specification) RAMP Simple rampgenerator. RATELIM Simple rate limiter generator. RATIO FF StandardRatio block. (From FF standard specification) RETENTIVE Simple retentivetimer. RS Simple reset dominant flip-flop. RUNAVE Simple running averagecalculator. SCALER Simple sealer. SIGGEN Generates square waves, sinwaves, random waves, or any combination of the three. SIGNALCHAR FFStandard Signal Characterizer. (From FF standard specification) SIGSELSimple signal selector. SPLITTER FF Standard Splitter. (From FF standardspecification) SR Simple set dominant flip-flop. SUBTRACT Simplesubtract block. TP Simple timed pulse block. TRANSFER Simple transferblock. XOR Simple exclusive or block.

[0092] At a definition and usage level of abstraction 530, theconfiguration architecture 500 includes definitions 532 and usages.Definitions 532 and usages, in combination, define the algorithm and theinterface for objects including function blocks, control modules,equipment modules, links and attributes. The definitions 532 definealgorithms and interfaces for function blocks, modules, links andattributes. Usages are objects and classes at the definition and usagelevel of abstraction 530 that represent the usage of one definitionwithin another.

[0093] At an instance level of abstraction 540, the configurationarchitecture 500 includes instances, which are “tagged” items within theconfiguration. Plant areas 542, modules 544, attributes 546, and PIOblocks 548 are tagged instances. Instances are defined according todefinitions 532. A plant area 542 represents a geographical or logicalsegmentation of a process site class 512. All objects and classes at theinstance level of abstraction 540 are defined throughout the plant arealevel so that all module instances have a 0 or 1 association with aplant area 542. To be installed in a run-time system, the moduleinstances must have a 1 association, meaning that the module is viewedas being “contained by” or “scoped” in this context of a plant area Amodule instance 544 is an installable object that is associated to aspecific object of plant equipment An attribute instance 546 is avisible parameter in a module instance 544, a plant area instance 542 orother device. An attribute instance 546 may be used for an input signal,an output signal, data storage or the like.

[0094] At a device level of abstraction 550, the configurationarchitecture 500 includes devices 552 such as controllers, smart devicesand consoles, and input/output devices (IO) 560 such as a PIO block, andthe like, which represent physical process control equipment in thephysical plant A process input/output (PIO) block is an abstraction thatrepresents various high density and low density conventionalinput/output devices including Hart, FieldBus and other input and outputdevices that are interfaced into the configuration architecture 500.High or low density relates to the number of channels on an I/O card.For example, 8 channels are typical on a low density card while a highdensity card may have 32 channels. Devices 552 are process controlequipment in the configuration architecture 500 and include objects suchas controllers, input/output devices, consoles and the like.Input/output devices (IO) 560 are the physical process input and outputdevices in the configuration architecture 500.

[0095] A smart device is a field device that is implemented to transmitand receive digital data pertaining to a device, including data relatingto device calibration, configuration, diagnostics and maintenance.Typically, the smart device is also adapted to transmit a standardanalog signal that is indicative of various information including, forexample, a process value measured by a field device. Examples of smartfield devices include field devices which follow a HART (highwayaddressable remote transducer) protocol, a Fieldbus protocol, a Modbusprotocol and a device net protocol.

[0096] Various hierarchical relationships among system objects areimplemented to facilitate navigation through the process controlenvironment 100 by different users and to accomplish different tasks.Four different hierarchical relationships are defined including control,control system, operations and physical plant hierarchies. A specificsystem object may be implemented in multiple hierarchical systems.

[0097] The control hierarchy is a subset of a standard SP88 hierarchyand has system objects including site, physical area, equipment module,control module and control element objects. The control hierarchy isused to organize control operations and to define the scope of namedobjects. A user interacts with the control hierarchy on the basis of asite instance, equipment module definitions, control module definitions,a plant area instance, equipment module instances, control moduleinstances, display module instances, and process I/O module(blockinstances, having signal tags.

[0098] The control system hierarchy includes operator/configurationstations, host computers, controllers, I/O devices, smart devices,gateways and the like, which are associated using various networkstandards including area control network (ACN), process control network(PCN) and other I/O network standards. In one embodiment, the ACNhardware includes standard 10-base-T ethernet communication ports and aworkstation contains standard Ethernet 10-base-T interface cards andsoftware drivers. A user interacts with the control system hierarchy onthe basis of a defined site instance, a network definition, a definednetwork instance, devices, and subsystems such as files, cards,channels, controllers, operation stations, and Fieldbus segments.

[0099] The area control network (ACN) includes communicationfunctionality at two levels, a remote object communications (ROC) leveland a low level communications level. ROC level controls the interfacebetween the Hawk applications and the ACN communications system. The lowlevel communications support the interface with the TCP/IP sockets andthe actual transmission of messages.

[0100] Remote Object Communications (ROC) are system operationssupporting communication of objects in the process control system 100and particularly supporting communication between objects whether theobjects reside in the same device or in remote devices. The ROCcommunication level supports communications message services includingrequest/response, unsolicited reporting, event/alarm reporting andbroadcast message service.

[0101] Request/Response is a service by which applications send messagesto a remote device and receive a response from the device. UnsolicitedReporting is a service for periodically sending updated data to a remotedevice. Unchanged data is not reported. Event/Alarm Reporting is aguaranteed delivery message service which is used for the transmissionof events, alarms and other vital information for delivery to a remotedevice. The broadcast message service is used to send messages to allHawk devices on the communications network. The ROC level also setscommunications policies for the communications subsystem. This meansthat it is responsible for managing what message get sent and when aswell as how incoming messages are processed. Communications flow controlwill also be the responsibility of the ROC portion.

[0102] Low level communications support is included for deviceconnection management, ACN redundancy and communications systemsdiagnostics. Device connection management establishes a communicationsconnection between two devices and manages the transmission of messagesbetween the two devices. ACN Redundancy handles the detection ofcommunications link failures, controls the switch from one link toanother and tracks the status of communication links between a hostdevice and connected remote devices. Communications subsystemdiagnostics tracks communication integrity and statistical information,responds to requests for communications diagnostic data.

[0103] Device connection management in an ACN communications systemsupports both UDP and TCP type device connections. UDP connections areused for normal real time data transfers between devices. TCPconnections are used for special applications using a streaming protocolsuch as file transfers, device flash downloads, and the like.Communications between devices is managed by a Device Connection Object.The Device Connection Object is transmits data and maintains the statusof the communications links between two communicating devices.

[0104] All normal device connection message traffic is directed througha single UDP communications port. A Device Connection Object starts thecommunications system by creating the communication socket associatedwith this UDP port as well as creating the queues needed for managementof the device connection message traffic. The Device Connection Objectreceives all incoming messages on a Device Connection communicationssocket and routes messages to the proper device connection instance forprocessing. The Device Connection Object handles timing functions ofdevice connections, including notifying device connection instances whenmessages time out waiting to be acknowledged, when communications linkchecks are due and when device connection resyncs have timed out.

[0105] UDP type communications are used for the transfer of real-timedata among devices. The remote object communications (ROC) subsystempasses messages to a UDP Device Connection for transmission to adestination device. A pool of message buffers is created on startup ofeach device. The message pool is used for all data transferred betweendevices, preventing the communications subsystem from exhausting memoryand ensuring that no other task exhausts memory, thereby preventing thecommunication subsystem from running. Communication flow control isimplemented in the Device Connection Object. If the number of messagebuffers in the communications buffer pool reaches a predefined lowlevel, all remote devices are inhibited from sending messages until thelow buffer problem is resolved in the affected device preventing loss ofmessages.

[0106] TCP-type communications are used for applications using astreaming-type protocol such as file transfers and device flashdownloads. TCP-type connections are temporary connections establishedfor the duration of the applications needs and terminated once theapplication has completed a communications task. For reasons ofinteroperability, compatibility, and availability, a TCP/IP protocolstack is employed. The TCP/IP stack supplies a connection-oriented, bytestream protocol (TCP) and a connectionless, message oriented protocol(UDP). The device connection supports request/response messages,unsolicited data, and event and alarm data between devices. Thecommunication system maintains the device connection through one of twoavailable communications links in the event of a single communicationsfailure, typically a cable fault. Detection of a fault and switch to analternate communications path transpires in a short, deterministic timespan which is less than one second.

[0107] The operations hierarchy is defined for a particular set ofusers, specifically operators and maintenance engineers, generally forthe purpose of accessing displays, reports, and other informationalitems. A user interacts with the operations hierarchy on the basis of asite instance, User Group definitions, a plant area instance, equipmentmodule instances, control module instances, display instances, andreport instances.

[0108] The physical plant hierarchy is defined for a particular set ofusers, specifically maintenance engineers and technicians, typically forthe purpose of determining physical relationships among objects andnavigating maintenance information about plant instruments andequipment. A user interacts with the physical plant hierarchy on thebasis of a site instance, a maintenance area instance, a plant areainstance, room instances, cabinet instances, node/device instances anddisplay instances.

[0109] The system objects that are implemented in the multiplehierarchical systems are arranged into a plurality of subsystemsincluding control, process I/O, control system hardware, redundancymanagement, event/alarm management, history services, process graphics,diagnostics presentation, user environment, management organization andfield management system (FMS) subsystems. The control subsystem includesroutines for configuring, installing and executing control modules andequipment modules. The process I/O subsystem is a uniform interface todevices including HART, Fieldbus, conventional I/O and otherinput/output systems. The control system hardware subsystem defines acontrol system topology, devices within the topology and capabilitiesand functions of the devices. The control system hardware subsystem alsoincludes objects and data structures for accessing device levelinformation indicative of status and diagnostics.

[0110] The redundancy management subsystem establishes a redundantcontext between primary and secondary control applications and managesswitching in context between the primary and secondary controlapplications. The redundancy management subsystem also maintains andmonitors redundant context diagnostic information including stateinformation and data latency information. Network redundancy isaccomplished using two separate Ethernet communications links ornetworks. The primary communication link is the preferred communicationspath. The secondary link is only used if the primary has failed.Communications switchovers are performed on a per device basis. Forexample, if device A is communicating with devices B and C and theprimary link to device C falls, device A continues to communicate withdevice B on the primary link but switches to the secondary link tocommunicate with device C. Each Ethernet link is a separate, dedicatednetwork having a dedicated set of IP addresses and a subnet mask.

[0111] The device connection object manages redundant communicationsincluding controlling when to switch to the secondary link and when toswitch back to the primary link. Each device in the process controlsystem tracks the communication status of all current links to remotedevices by periodically sending link test messages when no othercommunications is occurring, to check the status of the communicationslinks to each device. Redundancy switchovers are performed on a deviceconnection basis.

[0112] The event/alarm management subsystem configures, monitors, andsupplies notification of significant system states, acknowledgments andpriority calculations. The history services subsystem stores andretrieves process and event information. The process graphics subsystemsupplies user-defined views for display and operator interfacing ontothe defined system architecture. The diagnostics presentation subsystemfurnishes displays of diagnostic information, typically at the requestof a user. The user environment subsystem supplies a user interface,allowing a user to enter commands to control operation of the processcontrol environment 100. The management organization subsystem sets anorganizational structure of the process control environment 100including specification of site, area, primitives, access to userlibraries, and location of defined objects and instances. The FMSsupplies user interfaces, views, and organization structure for theconfiguration, installation and monitoring of HART and Fieldbus devices.

[0113] A Fieldbus device implements localized control of a processwithin the process, in contrast to a longer-used and more conventionalapproach of controlling device functions from a main or centralizeddigital control system. A Fieldbus device achieves localized control byincluding small, localized controller/multiplexers 110 which are closelyassociated with field devices within the Fieldbus device. The small,localized controllers of a Fieldbus implement standardized controlfunctions or control blocks which operate on the field devices withinthe Fieldbus device and which also operate on other smart field devicesthat are connected to the Fieldbus device.

[0114] Thus, the process control environment 100 implements smart fielddevice standards, such as the Fieldbus Hi standard, Profibus standard,CAN standard and other bus-based architecture standards so thatcommunications and control among devices, particularly Fieldbus devices,are performed so that Fieldbus-type control operations are transparentto a user.

[0115] The process control environment 100 allows attachment to asubstantially unlimited number and type of field devices including smartdevices, such as Fieldbus and HART devices, and conventional non-smartdevices. Control and communication operations of the various numbers andtypes of devices are advantageously performed simultaneously and inparallel.

[0116] The process control environment 100 implements and executes astandard set of function blocks or control functions defined by astandard Fieldbus protocol, such as the Fieldbus HI standard, so thatFieldbus-type control is achieved with respect to non-Fieldbus-typedevices, such as a HART device 134 and a conventional device 136. Inaddition, the process control environment 100 enables Fieldbus devicesto implement the standard set of function blocks and control functions.Advantageously, the process control environment 100 implements anoverall strategy as if all connected devices are Fieldbus devices. Thisimplementation is achieved, in part, by the usage of a function block asa fundamental building block for control structures. These functionblocks are defined to create control structures for all types ofdevices. Usage of function blocks as fundamental building blocks isdescribed in FIGS. 6, 7, 8 and 9.

[0117] The process control environment 100 implements an overall,user-developed control strategy through the definition of functionblocks and control modules by downloading or installing specificportions of the control strategy into Fieldbus devices and non-Fieldbusdevices. Thereafter, the Fieldbus devices automatically perform thedownloaded portions of the overall strategy independently of othercontrol system operations. For example, the portions of the controlstrategy downloaded or installed into the devices operate independentlyof and in parallel with the control operations of thecontroller/multiplexers 110 and the workstations, while other controloperations manage the Fieldbus devices and implement other portions ofthe control strategy. In effect, the process control environment 100implements a control strategy using the controller/multiplexers 110within the Fieldbus devices.

[0118] An example of the definition of a function block 522 is shown inFIG. 6. Specifically, FIG. 6 depicts an “elemental” function blockdefinition 600 which is defined to contain only primitive objects. Theelemental function block definition 600 defines a sum function andincludes a “+” primitive 610, a first input attribute 612 which is afirst parameter 614 applied to the primitive 610, and a second inputattribute 622 which is a second parameter 624 applied to the primitive610. The primitive 610 produces a result that is supplied as an outputattribute 630. In this example, the elemental function block definition600 is a block definition that is created and named SUM.

[0119] A second example of the definition of a function block 522 isshown in FIG. 7. Specifically, FIG. 7 depicts a “composite” functionblock definition 700 which is defined to contain one or more elementalfunction blocks 600 and, optionally, one or more primitive objects. Thecomposite function block definition 700 defines a composite sum functionand includes a first SUM elemental function block 710 and a second SUMelemental function block 712, each of which is the same as the SUMelemental function block 600 illustrated in FIG. 6. The compositefunction block 700 has a first input attribute 720 and a second inputattribute 722 which are respective first and second parameters 724 and726 applied to the first SUM elemental function block 710. The firstelemental function block 710 produces a result that is applied to thesecond SUM elemental function block 712 as a first parameter 730. Thecomposite function block 700 has a third input attribute 728 that is asecond parameter 732 applied to the second SUM elemental function block712. The second SUM elemental function block 712 produces a result thatis supplied as an output attribute 734. In this example, the compositefunction block definition 700 is a block definition that is created andnamed SUM3.

[0120] An example of the definition of a control module 440 is shown inFIG. 8. Specifically, FIG. 8 depicts a control module definition 800which is defined and contains various input attributes 810, elementalfunction blocks 820, a first SUM3 composite function block 830 and asecond SUM3 composite function block 832. The exemplary control module440 includes five input attributes 810 which are connected to fiverespective elemental function blocks 820, three of which are parametersapplied to the first SUM3 composite function block 830. The first SUM3composite function block 830 produces a result that is supplied as aparameter to the second SUM3 composite function block 832 in combinationwith parameters supplied by the remaining two elemental function blocks820. The second SUM3 composite function block 832 produces a result thatis supplied as an output attribute 840. In this example, the controlmodule 800 is a control module definition that is created and named CM1.

[0121] Examples of a module instance 544, specifically a control moduleinstance, are shown in FIG. 9. Control module instances 910 and 920 arecreated in accordance with the CM1 control module definition so thateach control module instance 910 and 920 includes five input attributes912 and 922, respectively, that correspond to the five input attributes810 shown in FIG. 8. Each control module instance 910 and 920 alsoincludes one output attribute 914 and 924, respectively, that correspondto the output attribute 840 shown in FIG. 8. In this example, thecontrol module instances 910 and 920 are control module instances thatare created and tagged CALC1 and CALC2, respectively.

[0122] Using a definition editor, a system user creates and namesdefinitions, such as the SUM elemental function block definition, theSUM composite function block definition and the CM1 control moduledefinition. Then, using a module editor, the system user creates andtags instances, such as the CALC1 and CALC2 control module instances.

[0123] Referring to FIG. 10, a flow chart shows an example of controlmodule execution at run-time. A run-time program includes a schedulerroutine. Scheduler routines are well-known in the computing arts. Thescheduler routine requests execution 1010 of a composite control module,for example the composite control module 440 with tag CM1 shown in FIG.8. The CM1 composite control module 440 initiates transfer 1012 of theinput attributes 820, causing any associated links, or attributeassociations, to transfer 1014. A database definition typically refersto “associations” while a runtime definition relates to “links”. Insteps 1016 through 1056 the CM1 composite control module 440 requestseach elemental function block 820, first SUM3 composite function block830 and second SUM3 composite block 832 to execute in turn.

[0124] Specifically, in step 1016 the CM1 composite control module 440requests each elemental function block 820 to execute. The elementalfunction blocks 820 initiate transfer 1018 of input attributes, forexample first input attribute 612 shown in FIG. 6. The input attributesof the elemental function blocks 820 request 1020 loading of values fromthe links transferred in step 1014. The links copy 1022 values fromsource attributes to destination attributes. The elemental functionblocks 820 execute block algorithms 1024. Upon completion of blockalgorithm execution, the elemental function blocks 820 initiate transferof output attributes 1026, for example output attribute 630 shown inFIG. 6.

[0125] In step 1028 the CM1 composite control module 440 requests firstSUM composite function block 830 to execute. First SUM3 compositefunction block 830 initiates transfer 1030 of input attributes, forexample input attributes 722, 724 and 726 shown in FIG. 7, from theelemental function blocks 820. In step 1032, first SUM3 compositefunction block 830 requests internal function blocks, for example, thefirst SUM elemental function block 710 and the second SUM elementalfunction block 712 shown in FIG. 7, to execute in turn. First SUMelemental function block 710 reads input attributes, executes a blockalgorithm and sets an output attribute in step 1034. Second SUMelemental function block 712 reads input attributes, executes a blockalgorithm and sets an output attribute in step 1036. First SUM3composite function block 830 initiates transfer of output attributes instep 1038. The output attribute of first SUM3 composite function block830 requests an associated link to copy the value from the outputattribute in step 1040.

[0126] In step 1042 the CM1 composite control module 440 requests secondSUM3 composite function block 832 to execute. Second SUM3 compositefunction block 832 initiates transfer 1044 of input attributes from thelinks connected to the first SUM3 composite function block 830 outputattributes. In step 1046, second SUM3 composite function block 832requests internal function blocks, for example, the first SUM elementalfunction block 710 and the second SUM elemental function block 712 shownin FIG. 7, to execute in turn. First SUM elemental function block 710reads input attributes, executes a block algorithm and sets an outputattribute in step 1048. Second SUM elemental function block 712 readsinput attributes, executes a block algorithm and sets an outputattribute in step 1050. Second SUM3 composite function block 832initiates transfer of output attributes in step 1052. The outputattribute of second SUM3 composite function block 832 requests anassociated link to copy the value from the output attribute in step1054.

[0127] In step 1056 the CM1 composite control module 440 initiatestransfer of output attributes and output attribute 840 requests a linkfrom second SUM3 composite function block 832 to copy the value of thesecond SUM3 composite function block 832 output attributes. In someembodiments, output function blocks push output values to auser-configured PIO block attribute (not shown). Thus, PIO attributesare “pulled” by function blocks while output function blocks push outputvalues to PIO Block attributes. Similarly, input function blocks pullinput attribute values from PIO Block attributes.

[0128] A user defines a module control strategy by specifying functionblocks that make up control modules and determine the control strategy.The user modifies or debugs a module control strategy by adding,modifying and deleting function blocks, configuring parametersassociated with the function blocks and creating a view to newattributes.

[0129] By defining function blocks and control modules, a user-definedcontrol strategy, application program or diagnostic program isrepresented as a set of layers of interconnected control objectsidentified as modules. A layer of the control strategy includes a set ofmodules which are interconnected in a user-specified manner. A moduletypically includes an algorithm for performing a specific function anddisplay components which are used to display information to a user. Amodule is optionally represented to include a set of input and outputconnections for connecting to other modules. A module may be consideredto be a “black box” which performs a specified function and is connectedto other modules via specified input and output connections.

[0130] Referring to FIG. 11, a display screen serves as a flow chartwhich shows an example of a module or application program LOOPSIM 1060at a highest layer of a control structure. The illustrated layer of theLOOPSIM 1060 application program includes an input attribute (AIN)module 1062 called AI1, a deadtime module 1064, a proportional,integral, differential (PID) control module 1066, an output attribute(AOUT) module 1068 and a simulate module 1070. Each of the illustrativemodules includes named input connections and output connections whichare connected to the other modules via lines. The set of modules, theinput connections and the output connections of the set of modules, andthe interconnections between modules define the operation of the LOOPSIM1060 application.

[0131] At a lowest level, a module is a set of interconnected functionblocks. At higher levels, a module is a set of interconnected submoduleswhich, in turn, may include a further set of submodules. For example,the PID control module 1066 is typically a set of interconnectedsubmodules which perform the different functions included in a PIDfunctionality. The input and output connections of the PID module 1066are an input connection and an output connection of one or more of thesubmodules within a next lower layer of the PID module 1066. Thesubmodules in the PID module 1066 optionally include other input andoutput connections sufficient to define the interconnections between thesubmodules.

[0132] An application, a module or a submodule, at any module level, isoptionally modified by a user to perform a slightly different functionor to perform the same function in a different manner. Thus, a useroptionally modifies the module, thereby modifying the control structure,in a desired manner. Specifically, a user optionally adds input andoutput connections to modules and extends the input and outputconnections of a module to a higher level module so customize modulesfor various applications. For example, a user optionally adds a newinput connection or output connection to the PID module 1066 to the“edge” of the PID module 1066 which makes the input connection andoutput connection appear as input and output connections to the PIDmodule 1066.

[0133] The process control environment facilitates the definition andmodification of the control structure by furnishing editing operationsin a plurality of control languages including IEC-1131 standardlanguages such as Field Blocks, Sequential Function Charts (SFC), LadderLogic and Structured Text. Accordingly, different types of users, fromdifferent control backgrounds use the different languages to writedifferent modules for implementing the same or different applications.

[0134] Control modules are specified to have several advantageouscharacteristics. Some control modules allow direct access to attributes.For example, some attributes, called “heavy” attributes, support direct(maximum performance) communications. Direct communications areadvantageously used for connecting function blocks and Control Modules,supporting event/alarm detection, and high performance trending, forexample. Some attributes are created automatically upon definition of acontrol module with a user having the option to promote or force aparameter to be exposed as an attribute of a Control Module. Otherparameters are made accessible through a module, such as a ControlModule, an Equipment Module, a PIO Block, or a Device, which containsthe parameter but direct communications performance of the attributesdoes not warrant the overhead incurred in supplying this performance.These parameters are advantageously accessed to supply informationrelating to control system tuning, debugging and maintenance. In someembodiments, these parameters are accessed by a general purposeparameter browser applications, which use services provided by taggedcontainers to reveal attributes, invokeable services, and subcomponentswithin the containers.

[0135] Referring to FIG. 12, a block diagram illustrates anobject-oriented method for installing a process I/O attribute block intoa PIO device through the operation of the control subsystem. A block ofdefined objects 1110 includes a site object 1112, a controller device1114, a controller I/O subsystem 1116, a PIO interface device 1118 and aPIO device 1120. Prior to installation of the PIO device, the controllerI/O subsystem 1116 is previously created. The PIO device 1120 is alsopreviously created, either by installation or downloading. The block ofdefined objects 1110 directs a detail pointer 1122 to a list of blockdefinitions 1124 to specify a particular type of object to be created bya create pointer 1126 directing the operation of a create block 1128.The block definitions 1124 includes a PIO input attributes (AIN) blockdefinition either as hardwired or by previous installation. Attributesof the specified object are set by a user through the operation of aneditor 1130. Prior to installation of the PIO device, an input attribute(AIN) block 1132 does not exist.

[0136] Prior to installing the AIN block 1132, a user creates the PIOdevice 1120 then sets up initial values for AIN block attributes usingthe editor 1130. The user also sets a period for view parameteracquisition. The AIN block 1132 is saved and then installed.

[0137] Referring to FIG. 13, a block diagram illustrates anobject-oriented method for linking a Control Module input attribute to aprocess I/O attribute. Prior to linking of the control module inputattribute to the PIO attribute, the PIO block AIN 1220 is previouslyinstalled and the control module 1210 is also installed. The userspecifies that a PIOIN attribute 1212 of the control module 1210 isconnected to an attribute input process variable PV 1214 and requeststhat a link be made. A link 1216 is made as the control module finds thePIOIN attribute and returns a corresponding attribute index, locates PIOAIN in a plant area, find the process variable PV attribute and returnsa corresponding attribute index, instructs the run-time linker 1216 tocreate a link with a source at the process variable (PV) 1214 and adestination at the PIOIN attribute 1212, creates the link and connectsthe link 1216. At end of a download, links are resolved by the linkedobjects.

[0138] Referring to FIG. 14, a block diagram shows an object-orientedmethod for linking a control module output attribute (AOUI) 1312attribute to a PIO output attribute (PIOAOUT) 1320. A control module1310 is previously installed and the control module output attribute(AOUT) 1312 is installed within the control module 1310. The userspecifies that the control module output attribute (AOUT) 1312 isconnected to the a PIO output attribute (PIOAOUI) 1320. The link is madeas the run-time implementation of the control module 1310 is sent amessage to form the connection, the control module 1310 finds the AOUTattribute, requests location of the PIOAOUT attribute 1320, creates alink 1322 and connects the AOUT attribute 1312 and the PIOAOUT attribute1320 to the link 1322.

[0139] Referring to FIG. 15, a block diagram shows an object-orientedmethod for reading values of contained PIO attributes. A PIO block 1410is previously installed and an output attribute (AOUT) 1412 ispreviously installed within the PIO block 1410. A user, for example anengineer, requests a detailed view of the block in which all attributevalues are displayed. The detailed display includes one or more sets ofdisplay groups, also called view definitions, associated with the PIOblock 1410. A proxy is previously established for the PIO Block 1410. Auser requests detail for the output attribute (AOUT) 1412. Attributenames and values for the AOUT block are presented by an applicationprogram requesting a proxy client routine to access a view, an AOUTproxy client setting a return view definition and creating an attributeproxy object, and the application program requesting the AOUT proxyclient to read out values for attributes named with granted privileges.The application program formats and displays the data Display groupparameters are part of an I/O block definition and are, therefore, notconfigurable. Display groups are defined for attributes. Information isadvantageously updated while a PIO block is not linked since displaygroups and view groups control updating of non-linked PIO attributesassociated with a block.

[0140] The process control environment 100 implements an overallstrategy as if all connected devices are Fieldbus devices not only bythe usage of a function block as a fundamental building block forcontrol structures but also by implementing an input/output architecturethat treats Fieldbus and nonFieldbus devices in the same manner. Thefundamental character of the input/output architecture is based oninstrument signal tags (ISTs) that furnish user-configurable names forall I/O signals including Fieldbus and nonFieldbus I/O signals.

[0141] From the perspective of a user, an IST binds a user-defined nameto a signal type, to a specific signal in the I/O subsystem, to a signalpath including an attribute and to a set of signal property settings.

[0142] ISTs are not installed in the manner of other system objects.Instead, signal properties inherent to the IST tag are combined with I/OPort and I/O Device properties that are made available when an I/O Cardis installed. The combination of IST, I/O Port and I/O Device propertiesfurnish information for creating a PIO function block in the run-timesystem. The signal path from ISTs is included in the script that definesI/O Function Blocks during installation of a module.

[0143] To communicate throughout the process control environment 100, anI/O type Function Block uses an I/O reference definition. An ISTsatisfies the specification for an I/O reference. Conventional I/Odevices, such as MTL devices, have an IST for each channel. Hart andFieldbus I/O devices may include an IST for each distinct “I/O signal”on a Port or in a field Device. IST names have system-wide scope andshare the name space of Modules, Devices, and Areas. In large systems,ISTs typically correspond to instrument signal names on instrumentationdrawings. In small systems, formal instrument drawings may not exist sothat no obvious IST names are inferred. Typically, ISTs areautomatically generated as cards are configured based on a devicehierarchy path representing a controller node, I/O subsystem, card andport so that arbitrary IST names are avoided. Typically most ISTs arecreated automatically when a new I/O card is defined. Formultiple-signal I/O devices, an IST is automatically created for only asingle “primary signal”. In addition to automatic IST creation, a usermay also create ISTs using an “Assign . . . ” menu available from theExplorer Node/IOsubsys/Port/Device tree with a Port or Device selectedor using a “New . . . ” menu available from the Explorer IST tree.

[0144] ISTs have a “signal type” property to ensure compatibilitybetween the I/O signal and the I/O Function Block(s) that accesses theI/O signal. Signal type is one of: AIN, AOUT, DIN, DOUT, PCIN, PCOUT.ISTs have a set of “signal-related” attributes specific to the signaltype (e.g. EUO and EU100 for a AIN, MOMENTARY or LATCHED for a DOUT,etc.). All signal sources with the same signal type have the same set of“signal attributes”. All other properties of the I/O subsystem objectsare held in card, port, or device attributes.

[0145] Fully configured ISTs have a fully qualified path to acorresponding signal in the I/O system, e.g.“CON1/I01/S01/C01/FIELD_VAL”. An IST may be created without a definedpath defined so that module configuration may be completed before I/Ostructure details are fully defined. Modules with I/O Function Blocksusing ISTs with no defined path may be configured and installed but therun-time system must deal appropriately with missing I/O paths ofmissing ISTs on I/O Function blocks. A signal source has no more thanone IST. Attempts to configure more than one IST with the same path arerejected.

[0146] A user may delete an IST, thereby deleting associated signalproperties and possibly leaving some unresolvable IST references in I/OFunction Blocks. A deleted IST does not affect card/port/deviceproperties with a normal display of the IST on the Port/Device in theExplorer tree indicating no associated IST.

[0147] I/O-interface Function Blocks have at least one IST-Referenceproperty. An IST-Reference property is either left blank to indicatethat the function block does not connect to a IST, or is designated witha valid IST name. An IST-Reference property in an I/O Function Block iscompatible with exactly one IST signal type. For example, theIST-Reference in the AI Function Block has an IST with a signal type“AIN” only. Several I/O Function Blocks are compatible with the same ISTsignal type.

[0148] For compatibility with Fieldbus I/O Function Block definitions,Fieldbus I/O Function Blocks have attributes such as XD_SCALE, OUT_SCALEwhich overlap with some of the signal properties in ISTs. When a validIST-Reference is made, the configured values of these overlappedFunction Block attributes are ignored in the Run-time system and thecorresponding properties from the IST are used instead. An engineerconfiguring Fieldbus I/O Function Blocks uses an indication of ignoredattributes when a IST reference is in place. Such an indication istypically presented on a display as grayed out and non-editable textwith values copied from the IST. The I/O Function Block holds a privatesetting for the ignored attributes which are typically downloaded andpromptly overridden. If the IST-Reference is removed, the setting forthese attributes retains utility.

[0149] I/O Cards, Ports and Devices are incorporated into aconfiguration by a user operating a user interface, either the Explorer™or the Module Definition Editor. The channels on conventional I/O cardsare called “ports” and treated as an I/O Port so that special caseterminology for conventional I/O is avoided. The user interface alsoallows a user to delete I/O Cards, Ports or Devices. Multiple I/O Cardtypes are supported including, for example, 8-chan MTL AI, 8-chan MTLAO, 8-chan MTL DI, 8-chan MTL DO, 4-chan MTL Thermocouple/RTD, 8-chanHART input, 8-chan HART output, and 4-chanSolenoid. Some I/O Card typeshave a combination of I/O Port types on the same I/O Card. Deletion ofan I/O Card deletes all subordinate Ports. Deletion of an I/O Portdeletes all subordinate Devices. Deletion of I/O Ports or I/O Devicesdoes not delete related instrument signal tags (ISTs), but the path ofthe IST path to the associated I/O signal no longer is operable. Ifanother I/O Port or I/O Device is created which has the same path, theIST automatically rebinds to the I/O Port or I/O Device, so long as thesignal type is compatible.

[0150] A user can initiate the Install of an I/O subsystem, whichinstalls or reinstalls all I/O Cards defined in the Subsystem. The usercan initiate the Install of a single I/O Card, which installs the cardproperties and all properties for subordinate I/O Ports and I/O Devices.

[0151] The Explorer™ and the Module Definition Editor configure the I/Osubsystem by accessing current signal values, status, and selectedproperties that are directly addressable as Attributes in the I/Osubsystem. The user displays a graphic indicative of the current statusof cards, ports, devices, and signal values and status by accessing therespective cards, ports, devices and signal values and status usingdevice hierarchy attribute path addressing (for example,“CON1/I01/C01/P01/FIELD_VAL”). I/O subsystem attributes are communicatedusing the physical device path (for example,CON1/I01/IC01/P01/D01/FIELD_VAL) for addressing in communicationsbetween devices. Communication of I/O subsystem attributes isadvantageously used to transmit attributes from a controller/multiplexer110 to a workstation 102, 104, 106 for display and from a first to asecond controller/multiplexer 110 for virtual I/O handling.

[0152] Referring to FIG. 16, a block diagram illustrates an organizationof information for an instrument signal tag. An system IST table 1510contains information relating to an IST including path information andpointers to a system object. A first pointer 1512 designates a signaltype which points to an attribute signal table 1520. A second pointer1514 designates an entry in the attribute signal table 1520.

[0153] Accessing of information using device hierarchy attributeaddressing advantageously allows system diagnostic displays to bedesigned and built for system integration checkout before Control Modulework is complete. Device hierarchy attribute addressing also supportsdirect addressing of I/O signals from Modules, bypassing the use of I/Ofunction blocks and avoiding I/O function block behavior. I/O Card, I/OPort and I/O Device identifiers are generally defined automaticallyaccording to slot position information and the like.

[0154] Referring to FIG. 17, a flow chart illustrates a method forbootstrap loading a control system throughout a network in the processcontrol environment 100, including the operations of assigning thecontroller/multiplexers 110 a set of IP Addresses, a node name and otherstartup information that is not stored in flash ROMs of acontroller/multiplexer 110. A process 1600 for assigning internetprotocol (IP) Addresses to a Controller upon its initial bootup includesthe step of associating a MAC address in a Boot server, a Windows NT™workstation, with a controller/multiplexer name 1610. The MAC addressalone designates the controller/multiplexer identity. In step 1612, thename of the controller/multiplexer is assigned an arbitrary device ID,and an ACN link number and a PCN network number that are determined bythe cable attached to the controller/multiplexer. In step 1614, an IPaddress of a device is calculated from the device ID, the ACN linknumber and the PCN network number. In step 1616, a UDP datagram, whichdesignates default primary and secondary IP addresses that are reservedfor booting nodes and includes the controller/multiplexer MAC address inthe UDP user data, is broadcast to a special UDP reserved boot portusing the default primary IP address for the source address on theprimary interface. In step 1618, the boot server matches the MAC addresswith the assigned name and IP addresses, and broadcasts the assignedname and IP addresses with an echo of the MAC address to the UDP bootport. By broadcasting, the problem of doing any routing or ARP staticentry manipulation is avoided. In step 1620, the controller/multiplexerreceives the datagram, checks the MAC address, and if the MAC addressmatches, sets the IP addresses and saves the node name and device ID. Ifthe datagram is not received, the procedure is repeated using thesecondary interface through the operation of branch step 1622. In step1624, the controller/multiplexer, using the new address, sends a messageto the boot server saying indicating that the controller/multiplexer isoperational.

[0155] In step 1626, a user enters a Device Name, Device MAC Address,ACN Link Number and PCN Network Number. The device ID can beautomatically assigned by configuration software. The communicationssubsystem calculates the devices three IP addresses from the configuredACN Link number, PCN Network Number and the assigned device ID. In step1628, controller/multiplexer or I/O card software is flash downloadedover the ACN network by passing messages and S-Record files betweendevices on the ACN.

[0156] Referring to FIG. 18, an object communication diagram shows amethod for creating a device connection for the active, originating sideof a connection. An application program in either a workstation or acontroller/multiplexer requests access to an attribute which iscontained in another device. A UDP communications connection to theother device is established by the communication services so that theattribute can be accessed. Creation of a device connection spans twoseparate application programs. The application program which initiatesthe connection by requesting data located in another device and theRemote Object Communications (ROC) Services application program thatactually sends the messages to the other device. If no connection existswhen the ROC Services process is ready to send a message to a device,the ROC services create a connection to that device.

[0157] Prior to creating the device connection, a device to be connectedhas a valid Device Table containing the source device, is operating andincludes an object RtDeviceConnection which monitors messages on thedevice connection port. After the device connection is created, aconnection is established between the two devices and anRtDeviceConnection instance is created in the active device to handlethe connection.

[0158] In step 1710, an application program sends a message getContainerto object RtSite which returns the object ID of the module found orcreated. In step 1712, object RtSite sends a Locate message to objectRtPlantArea which locates the module and return its object ID. In step1714, object RtSite sends a GetDevice message to object RtDevice whichreturns the object ID of the device containing the module. In step 1716,assuming that a proxy for the remote device does not exist, objectRtDevice sends a Create message to object RtDeviceProxy. In step 1718,object RtDeviceProxy creates an instance of object RtDeviceProxy usingtemplate RtNew. In step 1720, object RtDeviceProxy asks objectRtDeviceConnection to GetDeviceConnectionlndex which returns the indexof the device name in the device connection table managed by objectRtDeviceConnection. In step 1722, object RtDeviceProxy registers thepointer to the RtDeviceProxy instance for the connected device bysending a RegisterPointer message to the object RtRegistry and returnsthe device proxy Object ID to object RtDevice. In step 1724, objectRtPlantArea sends a Create message to object RtModuleProxyClient tocreate a proxy client for the remote module. In step 1726, objectRtModuleProxyClient sends a Create message to object RtModuleProxyServerto create a proxy server for the module in the remote device. In step1728, object RtModuleProxyServer builds a create proxy server messageand asks object RtRocReqRespService to SendRequest to the remote device.In step 1730, object RtRocReqRespService Appends the message to theOutbound Message Queue for the ROC Communications Services process tosend to the remote device. In step 1732, object RtRocReqRespService inthe ROC Comm Services process issues a RemoveFirst command to theOutbound Message Queue and gets the create proxy server message. In step1734, the RtRocReqRespService sends the message by issuing a sendMsgcommand to the aRtDeviceProxy instance for the destination device. Instep 1736, the aRtDeviceProxy instance issues a GetDeviceConnectioncommand to RtDeviceConnection to get the Object ID for theRtDeviceConnection instance for the destination device. Assuming that adevice connection does not already exist, in step 1738, objectRtDeviceConnection performs a createDeviceConnection. In step 1740,object RtDeviceConnection creates an instance of RtDeviceConnectionusing template RtNew. In step 1742, object RtDeviceConnection registersthe pointer to the RtDeviceConnecfion instance by sending aRegisterPointer message to the object RtRegistry and returns the deviceconnection Object ID to object RtDeviceConnection. In step 1744, objectRtDeviceConnection sends a startActiveConnection message to theaRtDeviceConnection instance. The aRtDeviceConnection instance performsthe necessary steps to establish the connection to the other device. Instep 1746, the RtDeviceProxy instance issues a sendMsg to theaRtDeviceConnection instance to send the create server message to theremote device. In step 1748, the aRtDeviceConnection instance sends themessage to the remote device over the newly created connection.

[0159] Referring to FIG. 19, an object communication diagram shows amethod for creating a device connection for the passive, listening sideof a connection. A request to establish a device connection is receivedfrom another workstation or controller/multiplexer. The communicationsservices establishes a UDP communications connection with the requestingdevice.

[0160] Previous to creation of the connection, a device to be connectedto is operating and contains an object aRtDeviceConnection which isready to establish a connection. Object RtDevice Connection exists inthe device and is listening for input messages in the form of a syncrequest. After the connection is created, a connection is establishedbetween the two devices and an RtDeviceConnection instance is created inthe passive device to handle the connection.

[0161] In step 1810, object RtDeviceConnecfion receives a sync requestmessage from a remote device. In step 1812, object RtDeviceConnectionsends a Create message to object RtDeviceConnection to create aconnection to the requesting device. Assuming that a device connectiondoes not already exist, object RtDeviceConnection performs acreateDeviceConnection in step 1814. In step 1816, objectRtDeviceConnection creates an instance of RtDeviceConnection usingtemplate RtNew. In step 1818, object RtDeviceConnection registers thepointer to the RtDeviceConnection instance by sending a RegisterPointermessage to the RtRegistry and returns the device connection object ID toobject RtDeviceConnection. In step 1820, object RtDeviceConnection sendsa Create message to object RtDeviceProxy to create a device proxy forthe requesting device. In step 1822, object RtDeviceProxy creates aninstance of RtDeviceProxy using template RtNew. In step 1824, objectRtDeviceProxy sends a GetDeviceConnectionIndex message to the objectRtDeviceConnection to have the index of the device in the deviceconnection table managed by RtDeviceConnection for later use. In step1826, object RtDeviceProxy registers the pointer to the RtDeviceProxyinstance by sending a RegisterPointer message to the RtRegistry andreturns the device proxy object ID to RtDeviceConnection. In step 1828,object RtDeviceConnection passes the sync request message to theaRtDeviceConnection instance for processing via the handleInboundMessagemethod. In step 1830, object aRtDeviceConnection sends a sync responsemessage back to the remote device to indicate successful completion ofthe Device Connection creation.

[0162] Referring to FIG. 20, an object communication diagram illustratesa method for sending request/response messages between devices. Theremote object communications (ROC) service in one device sends a requestmessage to the ROC service in another device. The request message isprocessed and a response message is sent back to the originating device.

[0163] Prior to sending messages, a UDP device connection is establishedbetween devices. Following the sending of request/response messagesbetween devices, a response message from a remote device has beenreceived and is ready for processing by ROC services.

[0164] In step 1910, a read attribute request is issued by anapplication program to an aRtDeviceProxy instance associated with aremote device. In step 1912, the aRtDeviceProxy instance builds arequest message to be sent to the remote device to read the attributevalue and asks the RtRocReqRespService to send the message using theSendRequest method. In step 1914, object RtRocReqRespService sends themessage to the instance of RtDeviceConnection associated with theconnection to the remote device using the send msg method. In step 1916,the instance of RtDeviceConnection then transmits the message to theremote device over the device connection. In step 1918, the instance ofRtDeviceConnection in the remote device receives the message andrequests the RtRocRouter class to route the message to the correctinbound message service. In step 1920, object RtRocRouter determinesthat the message is a request/response message and requests objectRtRocReqRespService to ProcessInboundReqResp. After the message isprocessed by the ROC services and the message consumer a responsemessage is built, in step 1922 object RtRocRqstRespService sends theresponse message to the originating device using the SendResponsemethod. In step 1924, the outbound message queue processing ofRtRocReqRespService sends the response message to the instance ofRtDeviceConnection associated with the connection to the source deviceusing the send_msg method. In step 1926, the instance ofRtDeviceConnection then transmits the response message back to theoriginal device. In step 1928, the instance of RtDeviceConnection in theoriginal device receives the message and requests the RtRocRouter classto route the message to the correct inbound message service. In step1930, object RtRocRouter determines that the message is arequest/response message and requests RtRocReqRespService toProcesslnboundReqResp.

[0165] Referring to FIG. 21 an object communication diagram illustratesa method downloading a network configuration. A user, followingcompletion of the device configuration for a system, initiates adownload to a controller/multiplexer. A device table configurationscript is built by the configuration application. Using communicationsservices , the configuration application establishes a device connectionwith the controller/multiplexer to receive the download and sends adownload script to the controller device. The controller/multiplexerreceives the download script messages and processes the device table. Instep 2010, a configuration download application program builds remoteobject communications (ROC) script download messages containing thedevice table download script. In step 2012, the Download applicationissues a GetDevice message to RtDevice to get the Object ID for theRtDeviceProxy for the remote device. In step 2014, the RtDeviceProxydoes not yet exist so a Create message is sent to RtDeviceProxyC tocreate the necessary device proxy object. In step 2016, RtDeviceProxyCsends a GetDeviceConnlndex message to RtDeviceConnection to get theindex of the device connection for the remote device in the deviceconnection table. In step 2018, the device connection does not yet existso aRtDeviceConnection object is created to manage the connection to theremote device. A lookup is performed in the database to find the remotedevice entry. The device communications data (for example, ID and IPAddresses) is retrieved from the database and a new entry is added tothe configuration devices connection table. This connection is markedpermanent in the connection table since the device initiated theconnection. In step 2020, a startActiveConnection message is sent to theaRtDeviceConnection object to establish a connection to the remotedevice. In step 2022, the aRtDeviceConnection sends an RtSyncMessage tothe remote device. In step 2024, the remote device receives theRtSyncMessage and attempts to find an entry in the device connectiontable for the sending device. In step 2026, no entry is found so a newentry is added to the device connection table for the sending device andaRtDeviceConnection object is created to handle the connection in thereceiving device. In step 2028, a RtSyncReplyMessage is created and sentback to the sending device containing the device connection index fromthe device table. The device connection is now established and ready tosend and receive messages. In step 2030, the RtDeviceProxyC sends acreate RtDeviceProxyS message to the remote device. In step 2032, theRtDeviceProxyS is created in the remote device. In step 2034, theDownload Application sends the download scripts to the remote device viaRtRocReqRespServices using the SendMsg call In step 2036,RtCommScriptDownload receives the Device Table script and processes eachdevice table item and stores the data in a database Registry used tohold configuration data. For controller/mulitplexers this processing isused to create RtDeviceConnection objects and add the objects to thedevice connection table, allowing the memory to be acquired on downloadrather than subsequently.

[0166] While the invention has been described with reference to variousembodiments, it will be understood that these embodiments areillustrative and that the scope of the invention is not limited to them.Many variations, modifications, additions and improvements of theembodiments described are possible.

What is claimed is:
 1. A process control system comprising: a fielddevice; a controller coupled to the field device; a workstation coupledto the controller, and a software system implementing a control strategyfor the process control system, the control strategy being selectivelyapportioned into a plurality of control strategy modules and selectivelydistributed among the field device, controller and workstation, thecontrol strategy modules operating mutually independently and inparallel.
 2. A process control system according to claim 1, wherein: thesoftware system further includes a user interface for interfacing theprocess control system to a user; and the control strategy isselectively apportioned and selectively distributed by the user.
 3. Aprocess control system according to claim 1, wherein: the field deviceincludes a control element; and the software system includes a controlstrategy module that is distributed to the field device.
 4. A processcontrol system according to claim 1 wherein the field device is aFieldbus standard device including a control element; and a controlstrategy module is distributed to the control element and operates as aFieldbus standard function block.
 5. A process control system accordingto claim 1, further comprising: a plurality of field devices including aFieldbus standard field device and a non-Fieldbus standard device.
 6. Aprocess control system according to claim 1 wherein the software systemfurther includes: a configuration program for configuring the controlstrategy modules and installing the control strategy modules among thefield device, controller and workstation, the distributed controllersretaining the configuration until reconfigured.
 7. A process controlsystem according to claim 1, wherein the control strategy modules areselectively installable by downloading a selected control strategymodule to a selected one of the field device, controller andworkstation.
 8. A process control system according to claim 1, whereinthe control strategy modules are objects in an object-orientedenvironment.
 9. A process control system according to claim 1 whereinthe plurality of control strategy modules are configured into acommunication services hierarchy including: a remote objectcommunications (ROC) level for communicating messages between twocontrol strategy modules in a same controller and between two controlstrategy modules in different controllers, and a low levelcommunications level for interfacing with communications hardware andtransmitting messages across the communications hardware.
 10. A processcontrol system according to claim 1, wherein the control strategymodules include a device connection object for controlling datatransfers between a plurality of devices, transmitting data, maintainingcommunication link status between two communicating devices andestablishing a communication link upon demand of a remote device.
 11. Aprocess control system comprising: a field device; a control meanscoupled to the field device for controlling the field device; aninterface means coupled to the control means for interfacing the controlprocess system to a user; and a control strategy means for implementinga process control strategy, the control strategy means being selectivelyapportioned into a plurality of control strategy modules and selectivelydistributed among the field device, control means and interface means,the control strategy modules operating mutually independently and inparallel.
 12. A process control system according to claim 11, wherein:the control strategy means is selectively apportioned into controlstrategy modules and selectively distributed among the field device,control means and interface means by the user.
 13. A process controlsystem according to claim 11, wherein: the field device includes a fielddevice control means for controlling field device operations; and thecontrol strategy means includes a control strategy module that isdistributed to and operational upon the field device control means. 14.A process control system according to claim 11 wherein the field deviceis a Fieldbus standard device including a field device control means forcontrolling Fieldbus standard operations; and a control strategy moduleis distributed to the field device control means and operates as aFieldbus standard function block.
 15. A process control system accordingto claim 11, further comprising: a plurality of field devices includinga Fieldbus standard field device and a non-Fieldbus standard device. 16.A process control system according to claim 11 wherein the controlstrategy means further includes: a configuration means for configuringthe control strategy modules and installing the control strategy modulesamong the field device, control S means and interface means, thedistributed controllers retaining the configuration until reconfigured.17. A process control system according to claim 11, wherein the controlstrategy means are selectively installable by downloading a selectedcontrol strategy means to a selected one of the field device, controlmeans and interface means.
 18. A process control system according toclaim 11, wherein the control strategy means are objects in anobject-oriented environment.
 19. A process control system according toclaim 11 wherein the plurality of control strategy means are configuredinto a communication services hierarchy including: a remote objectcommunications (ROC) level for communicating messages between twocontrol strategy means in a same controller and between two controlstrategy means in different controllers, and a low level communicationslevel for interfacing with communications hardware and transmittingmessages across the communications hardware.
 20. A process controlsystem according to claim 11, wherein the control strategy means includea device connection object for controlling data transfers between aplurality of devices, transmitting data, maintaining communication linkstatus between two communicating devices and establishing acommunication link upon demand of a remote device.
 21. A method ofoperating a process control system including a distributed controllerand a distributed field device comprising the steps of: defining acontrol strategy including the steps of: building a plurality offunction blocks and control modules; and downloading user-specifiedfunction blocks and control modules selectively among the distributedcontroller and the distributed field device; executing the functionblocks and control modules distributed to the controller and distributedto the field device mutually independently and in parallel.
 22. A methodaccording to claim 21 wherein the process control system includes aplurality of distributed controllers and a plurality of distributedfield devices, the field devices including Fieldbus standard devicesexecuting Fieldbus standard function blocks.
 23. A method according toclaim 21 wherein the process control system includes a plurality ofdistributed controllers and a plurality of distributed field devices,the field devices including Fieldbus standard devices executing Fieldbusstandard function blocks and nonFieldbus standard devices executing inthe manner of Fieldbus standard function blocks